Day 2｜傳統 Application 與 LLM Application 有什麼不同？

上一篇提到，隨著 LLM 被大量導入各種 Application，新的資安問題也開始受到關注。

那麼問題來了：

LLM Application 和我們過去熟悉的 Application，到底有什麼不同？

要理解 LLM Security，我認為可以先從這個問題開始。

傳統 Application 怎麼運作？

以一般 Web Application 為例：

使用者
↓
Web Application
↓
Backend
↓
Database

使用者送出請求後，系統通常會依照開發者預先設計好的程式邏輯進行處理。

例如登入功能：

輸入帳號密碼
↓
Backend 驗證
↓
Database 查詢
↓
登入成功 / 失敗

因此，傳統 Application 的行為通常比較容易預期。

LLM Application 有什麼不同？

加入 LLM 後，架構可能變成：

使用者
↓
Application
↓
Prompt / Context
↓
LLM
↓
Generated Response

例如使用者對 AI 說：

「幫我分析這份文件，並整理出三個重點。」

Application 會將使用者的要求，以及可能存在的 Context、文件內容等資訊交給 LLM，再由模型產生回答。

這時候最大的變化就是：

Application 不再只有傳統程式邏輯，還加入了一個具有生成能力的模型。

最大的差異：自然語言

傳統 Application 通常會要求使用者按照特定格式輸入資料。

例如：

帳號：________
密碼：________

但 LLM Application 的輸入可能是一整段自然語言。

例如：

「幫我把這份報告整理成主管看得懂的版本。」

使用者甚至可以用完全不同的方式表達相同意思。

因此，自然語言本身就成為 LLM Application 很重要的輸入介面。

而這也帶來一個新的問題：

使用者輸入的到底只是「資料」，還是也可能是在對模型下「指令」？

這是傳統 Application 比較少遇到的問題。

LLM Application 的另一個差異

實際的 LLM Application 通常也不只有 LLM。

例如加入 RAG 後：

使用者
↓
Application
↓
RAG / Knowledge Base
↓
LLM
↓
回答

如果再加入 API 或 Tool，LLM 甚至可能參與取得資料或執行某些操作。

因此，LLM Application 的安全範圍可能包含：

使用者輸入
Prompt
Context
LLM
外部資料
API / Tools

攻擊面自然也會比單純的 Application 更複雜。

傳統 Security 還有用嗎？

當然有。

LLM Application 本質上仍然是一個 Application，所以 SQL Injection、XSS、Authentication、Authorization 等傳統安全問題仍然需要處理。

只是現在多了一個 LLM。

因此可以簡單理解成：

LLM Security 並不是取代傳統 Application Security，而是在傳統 Security 的基礎上，增加新的安全問題。

小結

傳統 Application 與 LLM Application 最大的差異，可以簡單整理成：